Abstract

Details

Abstract

k1psl shows IPC errors (see also Fig.1) after removing k1mzm reported in klog#29540.
For removing these errors, I updated and restarted k1psl.

Details

IPC connections which had errors were terminated on k1psl as shown in Fig.2. So I removed these unnecessary Dolphin blocks from k1psl. After then, the model file was re-compiled, installed and restarted. I also removed these unnecessary Dolphin connection from the IPC list (/opt/rtcds/kamioka/k1/chans/ipc/K1.ipc, see also Fig.3) and the channels on k1mzm from the DAQ list (/opt/rtcds/kamioka/k1/target/fb/master, see also Fig.4). Finally, k1mzm was removed from the real-time model list (/diskless/root/etc/rtsystab, see also Fig.5).

Due to the above works, removing k1mzm should have been completed.

Abstract

Recovering Real-time front-ends and DAQs

Reverting unsaved oplev set points

Memo

ETMX was tripped at 21:56 JST on 10th May as shown in Fig.1 because F3 GAS signal reached the watchdog threshold.

Guardian request was changed READY and TWR_DAMPED many times before VIS_ETMX went to TRIPPED.
There is no guardian node requesting VIS guardians to TWR_DAMPED in my remember. So it seems to be someone's activities.
Because I couldn't know current situation (it's unexpected behavior or a result of someone's activities), I keep it TRIPPED.

[Kamiizumi, Tomura, YamaT]

This is a similar work with klog#29211

Abstract

We added the latch function in order to switch input gain of CARM common mode servo without making serious glitches.
k1alspll and DAQ were restarted to apply the update of the real-time model.
After updating model, glitches at the timing of switching gain is drastically mitigated same as the case of IMC common mode servo.
 

Details

In order to mitigate glitches due to the timing gap between ON and OFF of the binary output, we applied a same model update as IMC servo to CARM servo. Common mode servo block with the latch function was prepared as the library in the last time. So today I just copied it to k1alspll model and restarted the k1alspll and DAQ for applying updates.

We also checked a glitch situation at the OUT2 port when gain was changed. Fig.1 and Fig.2 show readout voltage without the latch function at OUT2 when IN1_GAIN was changed as 16dB->15dB and 15dB->16dB, respectively. As same as IMC case, there is a timing gap as ~100us between ON and OFF of the binary output. In Fig.2 (15dB->16dB), multiple glitches can be seen around t=100us. It seems to come from a timing gap of turning OFF 1, 2, 4, and 8dB stages. In the case of IMC servo, we couldn't find such behaviors. So a presence of such behavior depends on individual differences of BO cards.

Read out voltage with the latch function is shown in Fig.3 (16dB->15dB) and Fig.4 (15dB->16dB). According to these plots, the latch function works fine also for the CARM servo. Let's check the improvement also on the lock acquisition after CARM and IFO comes back.

Abstract

Details

MEDM time machine works well.
It can show past values recorded in frame files on MEDM screens and can be launched from the MEDM execute menu.

After choosing a lock back time as relative time, gps time, local time etc. (see also the left windown in Fig.1), a new MEDM screen is launched. Channels not recorded in frame files such as _OUTMON are displayed as white boxes instead of record values as shown in the bottom window in Fig.1

Abstract

I was informed by Uchiyama-san that the IYA vacuum readout on the digital system had stopped.
It was caused by some troubles on the VLAN switch and problem was solved by using an another network switch.
Vacuum DAQ for IYA came back online around 14:27 JST.
 

Details

When I was informed by Uchiyama-san that the IYA vacuum readout was stopped, I couldn't access RaspPi@IYA via the network. So I asked Uchiyama-san to unplug/replug a UTP cable and after then a USB power cable. But RaspPi@IYA was still unreachable. Because it's difficult to continue the recovery work remotely, I went to IYA to access the RaspPi.

According to my inspection at IYA, the RaspPi system seemed to work fine and NIC was lined up properly. At first I doubted a failure on an UTP cable or a LAN port on the switch, but there was no improvement even if I replaced an UTP cable and changed a LAN port. Next, I doubted VLAN setting was something changed. So I changed a network configuration of RaspPi from static IP to DHCP because I expected that IP address for DGS or CATV was assigned instead of one for ICRR. But IP address was assigned as ICRR segment.

This situation seemed to be a problem on firewall like system not a network connection itself. So I stopped RaspPi and connected it to the network switch at BS workstation area for the DGS network and one at Cryocon rack at IXC for the ICRR network. On both network, RaspPi became reachable. So I could localize the problem on the network switch at IYA.

Finally, I asked Oshino-san about the port assignment of two VLAN switches at IYA and the UTP cable for the RaspPi was moved from port#7P of the left switch to port#3 of the right switch (see also Fig.1 and Fig.2). Then, vacuum readout on the digital system came back online around 14:27 JST.

According to the DQ channel as shown in Fig.3, Readout of IYA seemed to stop around 9:53 JST on Feb. 21st. Though it came back online once around 10:48 JST on Feb. 24th, it was stopped again around 14:44 JST on Feb. 27th.

[Tomura, Kamiizumi, YamaT]
 

Abstract

We updated the IMC model to mitigate glitches coming from a timing gap of the BO operation, which makes a lockloss related to IMC and/or CARM controls.
Now, changing gain on MC common mode servo can be done more smoothly same as the test on the standalone system.
Because we cannot output laser today due to another works, we haven't tested this code with locked IMC yet.
 

Details

When we faced locklosses related to the gain change of IMC servo first time, we doubted the difference on the offset between 16dB and 15dB as a cause of lockloss (see also klog#26657). But we found larger change in offset during a gain change than the offset difference between 16dB and 15dB by some tests on the standalone system as discussed in the thread of klog#29112. Changing gain especially for 16dB->15dB and 8dB -> 7dB by BO makes glitches because delay of photocoupler is different between ON and OFF. BO supported by LIGO RCG has an asymmetric delay as 200us (maximum). So, when we change a gain from 16dB (0b10000) to 15dB (0b01111), the actual change is 16dB (0b10000) -> 31dB (0b11111) -> 15dB (0b01111) within 200us as shown in Fig.1. Finally, we could mitigate this glitch by preparing a new real-time model to mitigate the timing gap of BO on the standalone system.

Because the new real-time model seemed to work fine on the standalone system, we installed it in the IMC model. By mitigating a timing gap of BO operation, a change in an offset voltage at OUT2 is also mitigated from Fig.1 to Fig.2 (Fig.1 was taken in last week because I forgot to save it today...). In the new real-time model, ON and OFF on BO operation can be done almost simultaneously. So we can change a gain from 16dB to 15dB not via 31dB. A situation in the case of 8dB -> 7dB is also improved from Fig.3 to Fig.4.

Latch and intentional delay can be controlled on the MEDM screen (see above IN1GAIN controller in Fig.5). Please keep "ON" for "Use Latch" button if you want to use latch function. When it's in "OFF", latch function is disabled. About a sample number of delay, we confirmed it worked well in N=0~2. Latch channel and gain channel are output from another BO cards each other because of the pin assignment. So this delay is prepared to compensate an individual difference of two BO cards if it's too large. When we will install this model also for CARM common mode servo, we must confirm same things.